-
Notifications
You must be signed in to change notification settings - Fork 169
install: Enable installing to multi device parents #1911
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request successfully enables installing to multi-device parent filesystems, such as LVM spanning multiple disks. It correctly discovers all parent devices and, for bootupd/GRUB, installs the bootloader to all devices with an ESP partition. For bootloaders that only support single-device configurations like systemd-boot and zipl, the implementation correctly defaults to using the first available device. The changes are well-architected, adapting data structures and logic to handle multiple devices. A new, thorough integration test validates both single and dual ESP scenarios. Overall, this is a solid enhancement with good error handling and logging. I have one suggestion to further improve the robustness of ESP detection.
| let devpath = dev.path(); | ||
| println!("Installing bootloader via bootupd to {devpath}"); | ||
| Command::new("bootupctl") | ||
| .args(["backend", "install", "--write-uuid"]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will lead to a kind of last-one wins behavior for bootupd.json - but in the end they should be identical I guess?
cc @HuijingHei
We probably want to document the right way to do multi-device installs there. (and have man pages in general)
Alternatively it might be nicer to explicitly support this in bootupd by just passing each device?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will lead to a kind of last-one wins behavior for
bootupd.json- but in the end they should be identical I guess?
Agree, but we need this like RAID.
Alternatively it might be nicer to explicitly support this in bootupd by just passing each device?
That will be cleaner, and we could do this only if we make bootupd not fail if the passed device does not have the esp device.
f2a175a to
f7b1892
Compare
|
waiting to merge until the patch release goes out |
77b65cb to
d03c6fa
Compare
d03c6fa to
9b1c313
Compare
6802697 to
081f3b2
Compare
When the root filesystem spans multiple backing devices (e.g., LVM across multiple disks), discover all parent devices and find ESP partitions on each. For bootupd/GRUB, install the bootloader to all devices with an ESP partition, enabling boot from any disk in a multi-disk setup. systemd-boot and zipl only support single-device configurations. This adds a new integration test validating both single-ESP and dual-ESP multi-device scenarios. Fixes: bootc-dev#481 Assisted-by: Claude Code (Opus 4.5) Signed-off-by: ckyrouac <ckyrouac@redhat.com>
081f3b2 to
9d0e284
Compare
When the root filesystem spans multiple backing devices (e.g., LVM across multiple disks), discover all parent devices and find ESP partitions on each. For bootupd/GRUB, install the bootloader to all devices with an ESP partition, enabling boot from any disk in a multi-disk setup. systemd-boot and zipl only support single-device configurations.
This adds a new integration test validating both single-ESP and dual-ESP multi-device scenarios.
Fixes: #481
Assisted-by: Claude Code (Opus 4.5)